Mobile IP is a mechanism for maintaining transparent network connectivity to and from a Mobile Node (MN), such as a mobile terminal or telephone, over an IP based network whilst the Mobile Node is roaming within or across network boundaries. Mobile IP enables a Mobile Node (or rather user) to be addressed by a fixed IP address (a “Home Address”) allocated by its home network, regardless of the network to which it is currently physically attached. The home address causes all traffic sent to the home address to be routed through the home network. Ongoing network connections to and from a Mobile Node can be maintained even as the Mobile Node is moving from one subnet to another. Mobile IP can be implemented using IP version 4 (IPv4) or IP version 6 (IPv6), although IPv6 is generally preferred as IPv4 has a number of limitations in a mobile environment. The IPv6 protocol is specified in RFC 2460, whilst Mobile IP using IPv6 is specified in IETF RFC 3775, ‘Mobility Support in IPv6’.
According to Mobile IPv6, a Mobile Node is always reachable via its Home Address. However, while away from its home IP subnet (Home Subnet), a Mobile Node is also associated with a Care-of Address which indicates the Mobile Node's current location. The association of the Mobile Node's Home Address and the Care-of Address is known as a “Binding”. A router in the Home Subnet, known as the “Home Agent”, maintains a record of the current Binding of the Mobile Node. The Mobile Node can acquire its Care-of Address through a conventional IPv6 mechanism called “auto-configuration” within the visited IP subnet.
Any node with which a Mobile Node is communicating is referred to as a “Correspondent Node”. The Correspondent Node can itself be either mobile or stationary. There are two possible modes for sending communications between the Mobile Node and the Correspondent Node.
The first mode, referred to as bidirectional tunneling, does not require Mobile IPv6 support from the Correspondent Node and is available even if the Mobile Node has not registered its current Binding with the Correspondent Node. IP packets from the Correspondent Node are routed to the Home Agent and then tunneled to the Mobile Node. Packets to the Correspondent Node are tunneled from the Mobile Node to the Home Agent (“reverse tunneled”) and then routed normally from the Home Network to the Correspondent Node. In this mode, the Home Agent intercepts any IPv6 packets addressed to the Mobile Node's Home Address and each intercepted packet is tunneled to the Mobile Node's primary Care-of Address. This tunneling is performed using IPv6 encapsulation.
The second mode, referred to as route optimization, requires the Mobile Node to register its current binding at the Correspondent Node. This is done using a Binding Update message sent from the Mobile Node to the Correspondent Node (which the Correspondent Node acknowledges with a Binding Update Acknowledgement message). The Binding Update message contains as its destination address the address of the Correspondent Node. The source address of the message is the Care-of Address of the Mobile Node, whilst the home address of the Mobile Node is contained within a home address field of the message header. Route optimisation requires the inclusion of a routing header (a type 2 routing header) in the packet headers, indicating that the packets must be dealt with in a special way.
In order to enhance security of the Optimised Routing process, a “proof-of-address” mechanism may be employed. One such mechanism requires that, prior to issuing a (first) Binding Update message, a roaming Mobile Node send to a Correspondent Node a first message (HoTI) to the Correspondent Node employing route optimisation and a second message (CoTI) not employing route optimisation. The second message travels via the Home Agent whilst the second does not. The Correspondent Node replies to the first message with a first part of a random number generated by the Correspondent Node, and replies to the second message with a second part of the random number. The Mobile Node will only receive both parts of the random number if it has given both a valid Care-of Address and a valid Home Address. When the Binding Update is subsequently sent to the Correspondent Node, the Mobile Node includes both parts of the random number in the message to prove ownership of the Care-of and Home Addresses.
Once implemented, Route Optimisation allows the Mobile Node to send packets directly to the Correspondent Node. The Care-of Address is included as the source address in these “outgoing” packets. This is done by the Mobile IP protocol layer at the Mobile Node, which replaces the home address with the Care-of Address as the source address in outgoing packets. The Home Address is included in a further header field. The Mobile IP protocol layer at the Correspondent Node screens incoming mails by comparing the source addresses of the packets with Care-of Addresses held in its binding cache. If a match is found, the Care-of Address is replaced with the corresponding Home address, in the source address field, before passing the message to higher layers. Transit through the home network is thus avoided.
Considering the reverse direction, packets from the Correspondent Node can be routed directly to the Care-of Address of the Mobile Node. When sending a packet to an IPv6 destination, the Correspondent Node checks its cached bindings for an entry for the packet's destination address. If a cached binding for this destination address is found, the node substitutes the destination address for the corresponding Care-of Address, whilst including the destination address (i.e. the Home address) in a further header field. Upon receipt of a packet at the Mobile Node, the Mobile IP protocol layer replaces the Care-of Address in the destination field with the home address of the Mobile Node. The packet is then passed to higher protocol layers. Again, transit through the home network is avoided.
Routing packets directly to a Mobile Node's Care-of Address ensures that the shortest communication path is used. It also eliminates congestion at the Mobile Node's Home Agent, whilst reducing the impact of any possible failure of the Home Agent or networks on the path to and from the home agent. Route optimisation is, from the point of view of a user's home network, an example of “local breakout” from the access network used by the user. Another example of local breakout may be the case where a user “connects” directly to a Correspondent Node without using Mobile IP to handle mobility.
An important function of any mobile core network is the enforcement of service level policies. These policies dictate, inter alfa, what particular users may and may not do, and what they will be charged. Another policy might dictate the Quality of Service (QoS) that particular users will receive. Service level policies, which might be thought of as general policy statements, are enforced using detailed policy “rules”. A single policy may require a set of policy rules. Each policy rule will comprise a first subject part identifying the packets that the policy rule will be applied to, and a second action part. The subject part may in some cases be a packet filter. Policy rules are installed into a node through which all traffic of the users pass or into multiple nodes, which collectively handle all traffic of the user.
In the case of 3GPP, it is envisaged that policing and charging functionality will be controlled from a so-called Policy and Charging Rules Function (PCRF) logical node, based on signaling from Application Functions (AF) providing high level services to users. Consider for example the IP Multimedia Subsystem (IMS) which is an architecture designed to provide access to a range of multimedia services via a 3G network. This architecture is illustrated in FIG. 1. When a call is set up over the IMS, the IMS Proxy Call/State Control Function (P-CSCF) acts as AF from a policy and charging point of view and informs the PCRF of the new session. In particular, the P-CSCF sends to the PCRF a descriptor of the IP flow, and an abstract definition of the QoS to apply. The PCRF has installed into it, for each user, a policy which describes how packet flows for that user are to be handled, i.e. allowed/denied services, charges, actual QoS, etc. [This may be installed manually into the PCRF or may be installed remotely, e.g. by a user's home network where the PCRF is located in a “visited” network.]
Considering this scenario in more detail, the AF will send to the PCRF a flow descriptor in the form of a five-tuple vector containing: (1) IP source address, (2) IP destination address, (3) an identification of the used transport protocol (e.g., TCP or UDP), (4) source port number and (5) destination port number. The PCRF applies the policy to this vector to generate a set of policy rules. For example, the policy may specify the charge and QoS to be applied to a call between the IP addresses and port numbers contained in the vector. The resulting rules will contain the five tuple vector as the subject part and the appropriate charging and QoS actions in the action part. The PCRF installs the policy rules into the traffic node at which the rules will be enforced. If the addresses/port numbers of a packet passing through the enforcement node match the filter part of a rule, the action specified at that rule is carried out. The traffic node is referred to hare as the Policy Enforcement Function (PEF) and, in the case of a cellular network incorporating GPRS, is usually located in a GPRS Gateway Support Node (GGSN), or an evolution of the GGSN.